前言回顧
技能解封初始篇章-非法隱身存取(O365 & Azure Cloud App Security)

已領取技能符石

解封技能樹(Start)

適合的勇者?
曾經遭逢資安事件打擊者。
資安事件觀望者。
資安探索者。
IT過路人。
資安潛水幫。
資安擺渡人。*

學完可以帶走甚麼?
種下資安的芽在自己心中讓資安意識更強大。
自己的資安生涯規劃師。
帶走心中的這棵樹,把樹傳出去。
你也可以是小小資安擺渡人。
單挑資安認證更有信心。

伊瑟瑞爾 VS 督瑞爾

戰爭手劄讓唯一秘魔通道守護
天使城中面對這麼強大的暗黑勢力,經過非常多歷史的戰役也留下的不少寶貴的戰爭手劄,除了抵禦外面的魔神紛擾外更害怕的其實是自己的同胞,無論是萌生叛變的想法或是受魔法控制成了暗黑團的殭屍天使都使著城內信任瓦解猜忌不斷。
有個煉金術士獻策想要把這些分散自各天使將士保管的戰爭手劄寶箱都同時受一道唯一的天使認證光束加持,一方面能集中受到保護,而另一方面也才能辨別敵我,而這光束會有專屬的高級秘術魔法唯一通道守護者,想通關是需要得到它的認證才行。
唯一秘魔通道的解析回到人類聽得懂的代名詞"應用程式代理"小弟先簡述一下此服務究竟為何?
一個同時能讓雲端和內部企業的應用系統程式供單一身分驗證就能夠登入運行作業,除了安全不打折外也大大簡化應用程式的管理方式。而 Azure Active Directory (Azure AD) 就是我們的 SSO 驗證保護屏障。
我們可在 Azure AD 驗證體制中新增合法需要用到的外部 SaaS 應用程式以及企業內部專屬的營運應用系統。用戶僅需登入一次就可以安全且有效的存取這些剛剛設立的內外部應用程式。同時也可藉由自動化佈建來降低管理成本。另外也支援可使用多重要素驗證 MFA 及條件式存取原則以供安全的應用程式存取保障。
應用程式 Proxy 流程架構
Application Proxy 透過 Azure AD 安全驗證模式對你所需的內/外部應用程式供"SSO"單一登入方式運行。
- 用戶端透過網站端點點選所需應用程式後,系統會將用戶導向到 Azure AD 驗證入口。
- 待用戶帳密驗證成功登入後,Azure AD 會對用戶端裝置發送暫時性的信任權杖。
- 用戶再將將權杖傳送到 Application Proxy,透過此服務來取出權杖的 UPN 和 SPN。進而要求傳送至 Application Proxy Connect 之中。
- 而如已設定 SSO 則 Connect 會代替用戶來對所需驗證的應用程式進行登入驗證。
- 最後透過 Application Proxy 回應 Connect 進而回傳給用戶來達到暢通使用應用程式的目的。
Application Proxy 有甚麼好處?
- 可透過條件式存取原則來管理因應不確定的環境或裝置不確定性的風險性。
- 可用 SSO 單一登入在安全框架下提高商務營運生產。
- 符合治理與合規性。(可透過目前最夯的 SIEM 安全性事件與監視報告,來檢視其應用程式的登入)
- 降低系統人力管理成本。(SSO 免去多種AP密碼的管理外,也避免因為需重複性協助用戶重設 AP 密碼,進而花太多的時間在重複性工作上降低生產力)
上述講的美好,但能否實踐才是重點,有哪些類型應用程式與 Azure AD 整合呢?
- Azure AD 資源庫應用程式 – Azure AD 內含上千種以上預先整合能使用的 Azure AD 來進行單一登入。
- 企業內部應用程式配合應用程式 Proxy – 使用 Application Proxy 時可整合企業內部網站型應用程式與 Azure AD 整合進行單一登入。
- 自行開發的企業應用程式 – 自家開發的企業應用程式可透過與 Azure AD 註冊成應用程式服務來進一步與 Azure AD 整合來做單一登入。
- 不在資源庫內的應用程式 – 支援將其他應用程式以網頁連結形式能呈現用戶帳密欄位,支援 SAML 或 OpenID Connect 通訊協定來達到整合 Azure AD 單一登入之用。
Application Proxy 適用類型為何?
重聲 Application Proxy 是為了能讓用戶安全遠端存取企業內部網站應用。其中仍包含雲端中執行的應用程式 Proxy 服務和企業內部伺服器主機執行的 Application Proxy Connect。
- 透過整合 Windows 驗證來進行網站應用程式
- 透過表單驗證存取網站應用程式
- 能公開 Web API 讓 Application Proxy 界接
- 躲在遠端桌面閘道之後的後端應用程式
- 能整合 ADAL 的用戶端應用程式
有無單一登入差異
- 單一登入,用戶帳密登打一次就能存取公司資源、SaaS 應用程式和內外部網站應用程式等...從 Azure AD MyApps 存取面板執行應用程式。資訊人員也可將帳戶集中管理,並根據群組成員資格自動新增移除用戶應用程式存取權。
- 無單一登入,用戶須記住每個應用程式的密碼並依照當下使用的應用程式來做登入。針對每個應用程式的管理包含用戶端帳戶都會落在資訊人員上。而用戶除了管理多組密碼的遺失或遺忘的風險外還要花費時間在登入應用程式。
補充小知識:
- UPN:由使用者帳戶名稱和 UPN 尾碼(DNS 網域名稱)組成。會用 "@" 符號來與尾碼連結來做表示。如:mosbbs2@gamil.com 在樹系所有安全性主體間,UPN 需具有唯一性。
- SPN:用戶端唯一識別服務的執行個體名稱。如在主機上安裝多個服務,每個服務都應該有它各自的 SPN。
如:你的全新主機打算建置成網站服務,而這每個網站各自服務下都有它專屬的唯一名,像是網域,網站 URI,網站主機名等等...
實作工坊
而光說不練怎麼行,實驗環境中會把持續關注的你/妳帶到小弟我的 wordpress.com Blog連結內容如下:
技能解封初始篇章-攔截應用服務(Application Proxy)
- Cloud Application Proxy 成本計價。
- Cloud Application Proxy Q&A。
- 簡易實作體驗。
上屆鐵人主題
如果有興趣對您有幫助也請多多支持,歡迎給小弟建議或互相交流!
Google Cloud 勇者的試煉
玩轉 Azure 於指尖隨心所欲